Use Verifiable Credential JWS signed using known JSON WEB Key. #102
Conversation
kdimak
force-pushed
the
vc-jwt-with-known-json-web-key
branch
from
f29769f to
e29a93f
Compare
|
@awoie and @David-Chadwick, can you both check to see if this PR breaks your implementations? |
|
We are not encoding our JWT keys in this way. When we first did the conformance tests there was no signature checking and we have not performed the tests since then. But the way this key is encoded will not allow us to check our signatures. |
|
@kdimak and @David-Chadwick -- the two of you (and possibly @awoie) will have to figure out the proper encoding format, then. We are not going to be able to merge this until you have consensus. |
|
@mirceanis what are your thoughts? |
|
In general, I'm fine with the PR. It won't have an effect on our implementation. But I guess @OR13 has some thoughts on how to use |
|
The use of the The use of |
| eyJhbGciOiJSUzI1NiIsImtpZCI6ImRpZDpleGFtcGxlOjB4YWIjdmVyaWtleS0xIiwidHlwIjoiSldUIn0.eyJleHAiOjE1NzMwMjk3MjMsImlhdCI6MTU0MTQ5MzcyNCwiaXNzIjoiZGlkOmV4YW1wbGU6YWJmZTEzZjcxMjEyMDQzMWMyNzZlMTJlY2FiIiwianRpIjoiaHR0cDovL2V4YW1wbGUuZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJuYmYiOjE1NDE0OTM3MjQsInN1YiI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsInZjIjp7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIiwiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjEiXSwiY3JlZGVudGlhbFNjaGVtYSI6W10sImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImFsdW1uaU9mIjoiRXhhbXBsZSBVbml2ZXJzaXR5IiwiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifSwiaXNzdWVyIjoiIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIkFsdW1uaUNyZWRlbnRpYWwiXX19.IC4Bqm8HyRG5nZYgG02KiGQpxSxQpkWgZ0gcmZmQYWD3wZWJnLzc_hSFDEAzW59SMhqBTEkWPDLnCai21KqCyyW2N6qVmNUFWjifdGYdx4i5ute8LOSw2Qr20tnrsY03qwJtzrnSkg7vVVtj996iShA1EnCwDp13l_RoTDh3ZBRy3VX5uTF32h6rbSEMBsxpkJSl7ZglQnUJcwOjRlGwUGpavcgLASZ0uYu5pc2RX0woFgez23R0gZkrDGlgbTlgacaCDtoAz4kqTTLYOMOAWWJG5DRGtvYGjVJwJy5iOi2Uwg53hDUMS2crnj5IPa1ABQthkMviFlWKsyIY9NWLVA |
There was a problem hiding this comment.
Some JWT implementations don't like the trailing newline. Can that be removed from this file?
e.g.
See trailing newline (0xa) with hexdump:
$ hexdump -C test/vc-data-model-1.0/input/example-016-jwt.jwt | tail -2
00000430 59 39 4e 57 4c 56 41 0a |Y9NWLVA.|
00000438
Check file size:
$ wc -c test/vc-data-model-1.0/input/example-016-jwt.jwt
1080 test/vc-data-model-1.0/input/example-016-jwt.jwt
Truncate by one character:
$ truncate -s 1079 test/vc-data-model-1.0/input/example-016-jwt.jwt
See trailing newline is no longer present:
$ hexdump -C test/vc-data-model-1.0/input/example-016-jwt.jwt|tail -2
00000430 59 39 4e 57 4c 56 41 |Y9NWLVA|
00000437
Other ways to do it: https://unix.stackexchange.com/questions/140727/how-can-i-delete-a-trailing-newline-in-bash
Now the JWT can be verified with this jose command (https://github.com/latchset/jose) (after saving the JWK to key.jwk):
$ jose jws ver -i test/vc-data-model-1.0/input/example-016-jwt.jwt -k key.jwk
There was a problem hiding this comment.
The VC issuer property is an empty string. Shouldn't it instead be omitted, or match the iss claim?
https://www.w3.org/TR/vc-data-model/#issuer:
The value of the issuer property MUST be either a URI or an object containing an id property.
https://www.w3.org/TR/vc-data-model/#jwt-encoding:
iss MUST represent the issuer property of a verifiable credential or the holder property of a verifiable presentation.
There was a problem hiding this comment.
Decoded JWT:
{
"alg": "RS256",
"kid": "did:example:0xab#verikey-1",
"typ": "JWT"
}
{
"exp": 1573029723,
"iat": 1541493724,
"iss": "did:example:abfe13f712120431c276e12ecab",
"jti": "http://example.edu/credentials/3732",
"nbf": 1541493724,
"sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"credentialSchema": [],
"credentialSubject": {
"alumniOf": "Example University",
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
},
"issuer": "",
"type": [
"VerifiableCredential",
"AlumniCredential"
]
}
}Previous decoded JWT:
{
"alg": "RS256",
"typ": "JWT",
"kid": "did:example:abfe13f712120431c276e12ecab#keys-1"
}
{
"sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"jti": "http://example.edu/credentials/3732",
"iss": "did:example:abfe13f712120431c276e12ecab",
"nbf": 1541493724,
"exp": 1573029723,
"nonce": "660!6345FSer",
"vc": {
"@context": [
"https://w3.org/2018/credentials/v1",
"https://example.com/examples/v1"
],
"type": [
"VerifiableCredential",
"UniversityDegreeCredential"
],
"credentialSubject": {
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science in Mechanical Engineering"
}
}
}
}Diff, after rearranging some properties for consistency:
@@ -1,29 +1,29 @@
{
"alg": "RS256",
"typ": "JWT",
- "kid": "did:example:abfe13f712120431c276e12ecab#keys-1"
+ "kid": "did:example:0xab#verikey-1",
}
{
"sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"jti": "http://example.edu/credentials/3732",
"iss": "did:example:abfe13f712120431c276e12ecab",
"nbf": 1541493724,
+ "iat": 1541493724,
"exp": 1573029723,
- "nonce": "660!6345FSer",
"vc": {
"@context": [
- "https://w3.org/2018/credentials/v1",
- "https://example.com/examples/v1"
+ "https://www.w3.org/2018/credentials/v1",
+ "https://www.w3.org/2018/credentials/examples/v1"
],
"type": [
"VerifiableCredential",
- "UniversityDegreeCredential"
+ "AlumniCredential"
],
+ "issuer": "",
+ "credentialSchema": [],
"credentialSubject": {
- "degree": {
- "type": "BachelorDegree",
- "name": "Bachelor of Science in Mechanical Engineering"
- }
+ "alumniOf": "Example University",
+ "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
}
}The Expiration time (exp claim) 1573029723 (2019-11-06T08:42:03Z) is in the past. This may cause verification to fail. How about set it to some date in the far future, or omit the claim/property entirely?
AlumniCredential is not in the example context currently but may be added soon: w3c/vc-data-model#783. UniversityDegreeCredential is in the context.
"credentialSchema": [] doesn't cause a problem for @spruceid's implementation, but I wonder if it is useful/necessary.
The new key id did:example:0xab#verikey-1 doesn't directly match the issuer did:example:abfe13f712120431c276e12ecab. But this is okay if we assume that did:example:abfe13f712120431c276e12ecab has did:example:0xab as a controller.
The signature on
example-016-jwt.jwt,example-016-jwt-presentation.jsonld,example-016-jwt-presentation-no-iss.jsonld,example-016-jwt-presentation-no-jti.jsonldis fixed using the RSA key in the example config.In the existent test cases, it's not known what key was used to prepare VC JWT in the test data (e.g.
example-016-jwt.jwt). Those defined atconfig.json.exampleorconfig.json.example.jwtdo not fit.VC JWS is generated from
using RSA key from https://github.com/w3c/vc-test-suite/blob/gh-pages/config.json.example:
Closes #101